Behavioral Interface Contracts for Java (Rice University CS TR00-366)

Programs should consist of off-the-shelf, interchangeable, black-box components that are produced by a network of independent software companies. These components should not only come with type signatures but also with contracts that describe other aspects of their behavior. One way to express contracts is to state preand postconditions for externally visible functions. These preand post-conditions should then be validated during evaluation or possibly even during compilation. If a function call fails to satisfy its contract, the run-time system should blame the faulty program component. Behavioral contracts in the form of assertions are well-understood in the world of procedural languages. Their addition to class and interface hierarchies in object-oriented programming languages, however, raises many new and interesting questions. The most complicating factor is that objects can pass between components and trigger callbacks. Another problem is that object-oriented languages allow objects to satisfy several interfaces at once. In this paper, we analyze existing approaches to adding contracts to class-based languages and show how they blame the wrong component in certain situations for breach of contract. We then present a conservative extension of Java that allows programmers to specify method contracts in interfaces. The extension is a compromise between a consistent enforcement of contracts and language design concerns. In the future, we plan to clarify the relationship between contracts and contract violations with a rigorous analysis. 1 Contracts and Assertions Beugnard, Jézéquel, Plouzeau, and Watkins [1] suggest that software components should come with contracts. They describe four levels of contracts: 1. syntactic contracts (type systems), 2. behavorial contracts (invariants, preand post-conditions), 3. synchronization contracts, and 4. quality of service contracts. Type systems and other syntactic contracts for components have been studied extensively in object-oriented, functional, and higher-order contexts [2, 10, 16]. Behavioral contracts have been studied in procedural contexts [11, 19, 20, 25, 26]. Behavioral contracts have also been added to object-oriented languages [4, 9, 12, 13, 14, 21, 22, 24]. Adding behavioral contracts to object-oriented languages, however, is subtle. Each of the referenced systems fails